IBIS Macromodel Task Group

Meeting date: 9 June 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
                            * Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC                       * David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                            * Nicholas Tzou
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:               Bob Ross
TI:                           Alfred Chong

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- None

--------------------------
Call for patent disclosure:

- None


-------------
Review of ARs:

- Mike LaBonte to post Michael Mirmak's latest Directionality document.
  - Superseded by the following AR.
  
- Michael Mirmak to submit the Directionality BIRD with the discussed changes.
  - Done - submitted as BIRD 178.1.

-------------
New Discussion:

- Arpad: I anticipate a motion to untable the optimization topics.
  - Ambrish, are you prepared to discuss Walter's proposal.
- Ambrish: We have not yet had a chance to discuss it.
  - Nothing for the meeting this week.
- Arpad: No need for a motion to untable this week.

- Arpad: Walter sent an email today.
  - He has something regarding the C_comp improvements proposal from Randy.
- Walter: [sharing "C_comp in IBIS" presentation]
  - IBIS describes hook up of C_comp for *deriving* I/V curves. [* for emphasis]
  - IBIS 6.0 spec. mentions "Data Collection" to determine I/V curves.
  - [Showing IBIS 5.0 Terminator Model diagram]
    - Don't have other good examples for I/O, Output, etc.
    - POWER Clamp Curve - for data derivation is hooked up to [Voltage Range]
      *value* or [POWER Clamp Reference] *value*.
    - People point out that it's referenced to something.
    - IBIS would say it's referenced to GND.
      - Can be thought of as node 0, but not necessarily.
    - GND Clamp curve - hooked to GND (often 0) or a [GND Clamp Reference]
      value, also relative to GND.
    - C_comp - for derivation of I/V curves it's hooked up directly to GND not
      to supply rails.
    - As long as the supply rails are static, it doesn't matter where C_comp is
      hooked up.
  - The IBIS 5.1 Terminator Model diagram is incorrect.
    - GND became the ground symbol on the diagram as an editorial mistake.
    - Symbol is typically interpreted as chassis ground, misleading.
    - We should stick with the 5.0 diagram's GND.
- Arpad: Is that a universally accepted interpretation of this ground symbol?
- Walter: I'm not sure what it means universally.
  - It's different from GND, and that is misleading and confusing.
- David: What we can say is that GND and this ground symbol are thought of as
         "0" in SPICE simulators.
- Radek: The ground symbol most typically is setting that node voltage to "0".
  - GND can be used as "0", but not as commonly as the ground symbol.
  - GND can be interpreted as a reference node, not "0".
  - IBIS should be able to have GND as the ground of the component, not
    necessarily "0".
- Arpad: It's in the eye of the beholder, not spelled out.
- Walter: IBIS says:
  - For C_comp_*, it tells you how to hook it up.
  - For C_comp, IBIS never specifies what it is between, other than when you
    are deriving I/V and v(t) and there are constant voltages on the rails.
- Radek: There is another picture of a v(t) derivation.
  - It shows C_comp connected to GND.
- Walter: As part of simulation or derivation?
- Radek: Simulation must be consistent with derivation.
- Walter: No, in the derivation you know that the rails are constant.
  - In that case it doesn't really matter.
  - IBIS 6.0, page 70, "Potential numerical problems ... C_comp ... may be
    handled differently by different simulators."  
  - It's the only text description of how to handle C_comp.  Very vague.
- Radek: I think the original intent was different from how we see it now.
  - It is a strange statement.
- Walter: I'm just making the point that IBIS doesn't describe how to hook up
          C_comp.
  - [Showing corrected Terminator diagram using A_pcref, A_gcref terminals]
  - When you're doing simulation (time varying rail voltages), this is the
    proper Terminator picture.
  - I think C_comp should be hooked to A_gcref, as opposed to "0" or GND.
  - I think C_comp to "0" is fundamentally wrong.
  - Randy and I have done simulations:
    - With a real power deliver network, there are significant differences when
      you hook up C_comp between the Model pad and "0" vs. hooking it up between
      the Model pad and A_pdref.
    - C_comp to A_pdref yields excellent agreement with a SPICE model.
    - C_comp to "0" or GND is incorrect.
  - Conclusion:
    - IBIS should recommend that Model makers use C_comp_* (informative).
    - IBIS should recommend or require that EDA tools connect C_comp to A_pdref
      or split it between power rails.
    - Similar to the way the Interconnect proposal says package models should
      not use node "0".
- Arpad: This connection makes a difference only if powered by non-ideal
         sources, i.e., through a package model.
- Walter: Correct.
- Arpad: This is the background for my next comment.
  - If we don't have enough info in the IBIS Model to associate the buffer with
    individual power and ground pins, we can't do much with Power Integrity.
  - This only starts to make sense if the [Pin Mapping] keyword is present.
  - Only makes sense when the Model maker can give us this info.
- David: Summary, this is only pertinent to Power Aware simulations.
- Arpad: Yes, now in terms of what we want to do about it:
  - We can't vaguely say "applies to power aware...".
  - We can say, "If [Pin Mapping] is present," do it this way.
- Walter: [Pin Mapping] or the new [Buffer Rail Mapping].
  - If the buffer is running with ideal rails, it doesn't matter.
  - If the buffer is not running with ideal reals, some sort of power
    distribution network, then it matters.
  - If the buffer supply is non-ideal, C_comp should be hooked up to the same
    rail supplying the buffer.
    - Local ground, not "0".
  - I think we all agree on this.
  - Getting the words right might take some work.
- Radek: I think the problem is the other way around.
  - We should describe what GND is, not redefine what C_comp is hooked to.
  - GND is really the reference for the output node, too.
  - If the model maker tells you the pull down ref is GND, you have to do it.
  - Yes, the ground symbol in the 5.1 diagram is wrong.
  - The "0" reference is wrong.
  - Let's describe the real floating reference GND.
  - Problem originated from the first IBIS spec, when it was global ground.
  - GND was never clarified.
  - Defining GND as the local ground is the sensible solution.
- Walter: I think we can all agree.
  - C_comp should not go to "0".
  - It should be going to some local ground.
  - We can hash that out.
- Radek: Yes.
- Arpad: Yes.
  - In the early 90s, even when there was only one C_comp, I had a slide for my
    IBIS courses.  Even in that first version I connected it to die ground, not
    node "0".
- Walter: Randy and I have done experiments.
  - We don't find that it matters much how the C_comp is split up amongst the
    rails, as long as you avoid node "0".
  - Unfortunately, one of the standard simulators out there connects it to "0".
- Radek: There is one location where the spec mistakenly equates GND and "0".
  - The mistake is only made once.
  - That reference should be changed to A_gnd.
  - Not too much to clarify, but we should be clear.
  - If you have a pseudo-diff buffer, you need a common node to connect them.
- Arpad: What is the suggestion or proposal to come out of this discussion?
  - Incorporate it into Randy's BIRD?
  - Create a separate BIRD?
- Walter: I think it's an editorial effort to address this in IBIS.
  - We adopt one of the suggestions.
- Mike L: I think it's more than editorial in nature.
- Arpad: How do we make that decision on what suggestion to adopt?
  - Do we need a BIRD to vote on?
  - I'm not sure the Editorial Committee can do this on its own.
- Walter: In Interconnect we agreed to finish interconnect and not address IBIS.
  - We agreed there had to be a separate effort to clean up GND in IBIS.
- Radek: I think a BIRD is needed and should be voted on.
  - It may take some time, and is probably beyond the Editorial Committee.
- Arpad: It could start as editorial, but certain changes need technical review.
- Walter: The whole thing is one big BIRD.
  - Let's start by reviewing and making the changes.
  - The ATM group might be too big to start tackling this one.
  - A small editorial group could work on it and bring it to the ATM.
- David: Assume we do adopt one of these two suggestions.
  - We preclude the EDA tool from connecting to "0".
  - How does the EDA tool define the ground clamp reference in a simulation if
    the user hasn't specified it in the simulation?
- Walter: Whatever element your SPICE deck uses provides voltage internally or
          you supply it externally.
  - In the buffer there is a voltage rail or a ground rail.
  - Now we are saying C_comp is hooked to one of those, not "0".
- Radek: Let me put it differently.
  - If we properly define the local ground, and it's available, then if you
    simulate a single buffer it really doesn't matter.
- David: A typical IBIS user uses a component with only one node, the output.
  - They place a triangle with only one point on their schematic.
  - The simulation tool defines the rails.
- Walter: No, the tool goes to the IBIS file to decide.
- David: The positive rail.
- Walter: IBIS specifies that the ground rail is zero volts in the
         [Voltage Range] case.
- Mike L: Isn't this problem for the Model maker?
  - The simulator should be able to connect any node it wants.
- Walter: One simulator's b-element connects C_comp to "0".
- Mike L: Are you saying that because one simulator does it Model makers depend
          on it?
- Walter: I'm not saying that.  I'm saying it's vague and undescribed.
- David: Isn't the problem that we allow the user to drop a one-node triangle on
         the schematic?
- Arpad: The tool is providing the nodes.
  - Either way, the spec doesn't define it properly.
- Walter: The spec didn't anticipate power delivery.
  - I don't think Model makers understand that.
- David: Since the default definition for the ground clamp reference value is
         zero, you're not going to change the behavior in the default case.
- Walter: Yes, it's not a disaster where default results change.
  - It only changes if you're doing power delivery.
  - Even if you don't have a Power Aware Model [ISSO_PU, etc.], if there is an
    external PDN then it will make a difference.
- Arpad: Okay, we are at the top of the hour.
  - This was a good discussion, and we will address it.
  - We're not going to solve it all today.
- Walter: Thanks, that was my intention.
- Arpad: We will continue next week.  Thanks everyone.

AR: Mike LaBonte to post Walter's "C_comp in IBIS" presentation.
  
-------------
Next meeting: 16 June 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
